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(54) Title: METHOD AND APPARATUS I OR ASYNCHRONOUSLY CALLING AND IMPLEMEN TING OBJECTS 
(57) Abstract 

A method and apparatus for asynchronously calling and implementing objects 
is disclosed. Object calls to perform an operation are performed asynchronously by 
calling the appropriate stub function from the client application and passing in the object 
reference, input parameters, and a pointer to a completion routine. The object reference, 
input parameters, and completion routine address are provided to a client-side execution 
environment. The client-side execution environment stores the completion routine address 
and transmits the input parameters to a server-side execution environment. The server-side 
execution environment calls a method in the server application that implements the requested 
operation. The server application performs the requested operation. Once the call has been 
responded to, the client-side execution environment calls the completion routine and passes 
it the output parameters to the requested operation. 'Hie client application can continue 
performing other asynchronous operations before the completion routine is called. To 
asynchronously implement an object that has been called, the appropriate method function 
in the server application is called which, in turn, calls an asynchronous operation. Once the 
asynchronous operation returns, the application responds to the client application. 
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METHOD AND APPARATUS FOR 
ASYNCHRONOUSLY CALLING AND IMPLEMENTING OBJECTS 



BACKGROUND OF THE INVENTION 

5 

1 . Field of the Invention 

The present invention relates to a method and apparatus for making asynchronous object 
calls and asynchronous object implementations in client applications and server applications, 
respectively. 

10 

2. Background 

Distributed object computing combines the concepts of distributed computing and object- 
oriented computing. Distributed computing consists of two or more pieces of software sharing 
information with each other. These two pieces of software could be running on the same 

15 computer or on different computers connected to a common network. Most distributed 
computing is based on a client/server model. With the client/server model, two major types of 
software are used: client software, which requests the information or service, and server 
software, which provides or implements the information or service. 

Object-oriented computing is based upon the object model where pieces of code called 

20 "objects "--often abstracted from real objects in the real world-contain data (called "attributes" in 
object-oriented programming parlance) and may have actions (also known as "operations") 
performed on it. An object is defined by its interface (or "class" in C++ parlance). The 
interface defines the characteristics and behavior of a kind of object, including the operations that 
can be performed on objects of that interface and the parameters to that operation. A specific 

25 instance of an object is identified within a distributed object system by a unique identifier called 
an object reference. 

In a distributed object system, a client application sends a request (or "object call") to a 
server application. The request contains an indication of the operation to be performed on a 
specific object, the parameters to that operation, the object reference for that object, and a 
30 mechanism to return error information (or "exception information") about the success or failure 
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of a request. The serve, a PP ,ica,,o„ reMiv£s tfe ^ and ^ ^ ^ 
— tano," The imptemerati0 „ satisflK me cIiem . s requK[ ^ 

*-* object. The ,mp,eme„ta„o„ incudes one o r mo re methods. which « , e J 
code m server applical , 0 „ , te aclua , |y do ^ wofk ^ Qf « o 
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necessary. The server application may also return exception information 

To n-Mte distributed object systems, the Object Management Grotto COMC", a 
_ o f computer software companies, propel me Common Object Request Bro e 
Arcnttecmre ("CORBA"). Under the CORBA standard, an Object Reoues, Brol ™ 
provt.es a communicatton hub for a„ objects ,„ the system nasstng the request ,„ h se™ ~ d ' 

- BM s System Object Mode, ("SOM",. On the client s,de. the ORB hand.es revests fort 
■mp ementatton of a method and the retated seiection of servers and method, When a c„„, 
app catton sends a revest to dte ORB for a method to be performed on an object the ORB 
vahdates the arguments comatned in me request against the interface for that object and 
patches the request ,„ the server appiication. starting me server a PP „a„o„ if necessarv O 

s! " 0M ta K - .0 

I! h rcqUeS '" ^ mf0ma ' i0n inC ' UdK ~ * *" fc *' W- of 

bjec Uhe operatton ,s being perform on. and any addition,, information stored for the request 

In addttton. the server-side ORB vaUdates each revest and its arguments. The ORB is a,so 
responsible for transmitting the response back to the client. 

Both the cent application and the server applicatton must have information about the 
ava ab e mterfaces, including the objects and operations that can be performed o„ those objects 
To factlttate the cotnmon sharing of interface definition, OMC proposed the Interface Der,„i,,„„ 
Unguage ( y. IDL is a deftnttiona, language (not a p„» g language, tha, is used to 
*-* an objeefs mterface: that is. me characteristics and behavior of a kind of object 

Revision"^ T 10 * diS ' ribUKd *** SySKmS imptera ^ OM °' CORBA 

Revston 2.0 specftcation. In a typical system tmplementtng o,e CORBA specification, interface 
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definitions are written in an IDL-defined source file (also known as a "translation unit"). The 
source file is compiled by an IDL compiler that generates programming-language-specific files, 
including client stub files, server stub files, and header files. Client stub files are language- 
specific mappings of IDL operation definitions for an object type into procedural routines, one 
5 for each operation. When compiled by a language-specific compiler and linked into a client 
application, the stub routines may be called by the client application, for example, to formulate a 
request. Similarly, the server stub files are language-specific mappings of IDL operation 
definitions for an object type (defined by an interface) into procedural routines. When compiled 
and linked into a server application, the server application can call these routines when a 

10 corresponding request arrives. Header files are compiled and linked into client and server 
applications and are used to define common data types and structures. 

In general, computer systems use one of three communication styles: (1) One-way 
communication; (2) Synchronous Communication; and (3) Asynchronous communication. If a 
client application in a distributed object system invokes a one-way request, the application sends 

15 the request and continues with other work without checking to see if the request was completed. 
The request truly would go only one way; the application sends the request to the server, but 
nothing ever returas from the server. If a client application invokes a synchronous 
communication request, the application transfers control to the ORB and cannot do anything until 
the request completed or failed. Synchronous communication are most appropriate when an 

20 application needed to send and complete requests in a certain order and the operations were of 
short duration. If an application invokes an asynchronous object call, the application does not 
wait for the request to complete before it continued with other work. In time-critical situations, 
asynchronous communication is the preferred style for object calls. Similarly, the 
implementations of objects in server applications could benefit if asynchronous communication 

25 were efficiently supported. 

Unfortunately, conventional distributed object systems do not support true asynchronous 
communication for object calls from a client application. For instance, the CORBA specification 
offers "deferred synchronous communication." In deferred synchronous communication, a 
requesting application periodically checks to see if the request has completed by continuously 

30 polling using the CORBA _Requestj>et jesponse operation or the CORBAjgetjiextj-esponse 
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Moreover. convemiona, dis,ribu,ed objec, systems support breads" which are streams 
- exee U „o„ toI branch off from . ^ ^ ^ ™ 

execu,,o„, however. tas fe „„„ disadvMage$ ^ ^ ^ J f ^ 
synch™* access to con™ da*, overa,, performance loss, and plarform depended 
Accordingly, .here is a need for a method rt a PP araros for ^ 
asynchronous object calls within a distributed objec, system 

MOrc ° Ver ' " 1 ** ' — - « ^ performs asvrKhrono,,, ^ 

....p,e.„en,at,ons wuhou, the use of threaded execution. 

SUMMARY OF THE INVENTION 

object 2 T imemi0n Pr ° VideS ' "** " ** ~ 
J« -Us. The present .nvention a,so satisfies the need for a meo™. and apparatus for 

performtng non-threaded asynchronous objec, impiementations. 

I" a preferred embodiment, me med,od for performing asynchronous objec, calls of the 
presen, mvenUon invo.ves i„vo*,„ 8 an operatton on an ob Je c by callmg a srub func.ion from a 
*« app.tca.ton. The Cent appiication provides the srub function wi,h me input parameters to 
operanon along with a pointer to a completion routine. The invocatton is sen , 0 . Z 
PPhcahon using an execution environment common ,o the chen, and server app,ica,io„ Z 
-~ app„ca,io„ impiements ,he operation on the objec, and provides a response ,„ 1 

eZl" °™ " * ^ * - «~ a PP ,ica,ion. ,he 

ecu ■„„ e„_, calls the completion routine with the operation's ourpu, parame,ers The 
-Picon routine should also determine whether or not the objec, ca„ wassLcL, 

Implementations can be performed asynchronously as we,,. During an asynchronous 
, a Cien, app,ica,,o„ requests that an option be perfo Jon an o^Z 
^ may be made synchronously or asynchronously as stated above,. The Z t 
arsmtrted to a server applicanon by an execufon environment accessible by W the client and 

wir,~ I f when " re,ues, ' s,r — 

a ca„ ,de„„f,er. ,f an asynctaonous med,* ,s called from *. server app,ica„o„, U,e server 
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application passes the call identifier and the address to a response ftinction to the asynchronous 
method. The asynchronous operation completes and calls the response function which, in turn, 
responds to the caller. 

By using these "callback" functions ("completion routine" and "response function"), both 
5 the client and server applications can continue doing other work without waiting within a 
particular function. Moreover, by permitting both client and server to execute asynchronously, 
different invocation styles may be used to suit a particular task. For instance, an object call may 
be performed asynchronously while its implementation is performed synchronously, and vice- 
versa, thus providing greater flexibility to the developer. 
10 A more complete understanding of the method and apparatus for asynchronously calling 

objects will be afforded to those skilled in the art, as well as a realization of additional advantages 
and objects thereof, by a consideration of the following detailed description of the preferred 
embodiment. Reference will be made to the appended sheets of drawings which will first be 
described briefly. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of a client/server computing system utilizing the method of the 
present invention. 

Figs. 2a and 2b are diagrams of alternative configurations for Common Execution 
2 0 Environment capsules . 

Fig. 3 is a diagram of a Common Execution Environment capsule and its core 
components. 

Fig, 4 is a diagram of the compilation and linking of IDL source code into client and 
server applications, 

25 Fig. 5 is a flow chart describing the steps involved in a synchronous object call 

Fig. 6 is a flow chart describing the steps involved in an asynchronous object call. 

Fig. 7 is a section of programming code performing an asynchronous object call. 

Fig. 8 is a flow chart describing the steps involved in an asynchronous invocation of an 

object. 

30 Fig. 9 is a section of programming code performing an asynchronous object 
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implementation. 

invent " " 3 Cta " * SCribin8 '** ta * <* me m 

F,g. a is a flow char, cubing Ae ^ mvolved jn an alKrna[jve 
method of the present invention. 

Fig. 13 is a diagram showing a PIF data structure. 
Fig. 14 is a diagram showing an entry data structure. 
Fig. 15 is a diagram showing an operation data structure. 
Fig. 16 is a diagram showing a union data structure. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

~ rrr now be made m dmii to the preferred ° f - ~ 
x mpks of whlch are illustrated m te accompanying drawjngs wherever 

reference numbers wi„ be used throughout the drawings to refer to the same or lUce parts. 

1- System Ovprvi^u; 

As iliustraied in Figure ,. Ihe mettal of [hc preM , invtn , lon 

* °" W °* l2 ' »* - *™ — or .he co« of . loca , 

area ne.wor,, A server confer „ commutes over a o us or I/0 eha™, 20 w„» ar, 
«, d,s k srorage subsysrem ,3. Tie server syaem , , mc.udes a CPU 15 and a memory 
7 for s„r,„ 8 curren, saI e infom auon *», program execurio, a porrion of me memory „ is 
fcdrcared ,o sWng me SQ ,es «, varies associared wi,h each funoon of te pr08ram whic „ „ 
curreruiy execuUng o„ rhe server computer. A clien, compuier 2, similar* inches a CPU 27 

spiay dev.ee 33. such as a v,deo d,sp la y rermma, (-VDT-, The ciier,, CPU 27 

30 :zr;;.r T rj disk s,ora8e -~ 33 - * - ~ « - - 



15 



20 



25 



BNSDOCID: <WO 9802809A1 I > 



WO 98/02809 PCT/US97/1 1879 

The client memory 23, preferably, includes a client application 77 that is linked to client 
stubs 79 (as discussed below) and loaded therein. Similarly, the server memory 17 includes a 
server application 87 linked to server stubs 89. In addition, both the client memory and the server 
memory include an execution environment ("CEE") 75, 85 (as discussed below), 
5 The client/server model as shown in Figure 1 is merely demonstrative of a typical 

client/server system. Within the context of the present invention, the "client" is an application 
that requests that operations be performed on an object while the "server" is an application that 
implements the operation on the object. Indeed, both the client and server application may reside 
on the same computer and within a common capsule, as discussed below. Most likely, however, 
10 the client and server application will reside on separate computers using different operating 
systems. The method of the present invention will be discussed with reference to two capsules 
running on separate machines. 

IT Distributed Computing Environment 

15 The method and apparatus of the present invention may be utilized within any distributed 

computing environment- In a preferred embodiment, the Common Execution Environment 
("CEE") 75, 85, which is a component of the Tandem Message Switching Facility ("MSF") 
Architecture, is used. The CEE activates and deactivates objects and is used to pass messages 
between client and server applications loaded in CEE capsules. The CEE may be stored in the 

2 0 memory of a single machine. More likely, however, the CEE and client and server applications 
will be loaded on multiple machines across a network as shown in Figure 1. The client-side CEE 
75 is stored in the client memory 23. The server-side CEE 85 is stored in server memory 17. 

The CEE uses a "capsule" infrastructure. A capsule encapsulates memory space and one 
or more execution streams. A capsule may be implemented differently on different systems 

2 5 depending upon the operating system used by the system. For instance, on certain systems, a 
capsule may be implemented as a process. On other systems, the capsule may be implemented as 
a thread. Moreover, client and server applications may be configured within different capsules 
contained on different machines as shown in Figure 1. Alternatively, the different capsules may 
be configured as shown in Figure 2. Figure 2a shows a client application 77 loaded in a single 

30 capsule 81 and a server application 87 may be loaded in a separate capsule 85. Both capsules, 
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however, are stored on the same m achi ne 21. Both me Cient and server apphcations may also be 

above, the method of the present invention win be descnbed with reference to the mu.t.ple 
capsule, mu,tip,e machine case. According.y, the client 12 and server machine 11 include a 
chent-s.de CEE 75 and a server-side CEE 85 loaded in their respective memohes 

Figure 3 shows a CEE capsu.e 70 contained, for example, in a client computer memory 
27 not shown) that includes the CEE 75 and certam of the core CEE components and 
implementations of objects contamed within Imp.ementation Libraries 71. The Indentation 
L.branes 71 inc.ude the client application 79 (or the server app.ication in the case of the server 
capsule) and eta. stubs 77 (or server stubs) generated from the IDL specification of the object's 
-nterface. as descnbed below. The Imp.ementation Libraries 71 and the CEE 75 interact through 
the down-cal.ing of dynamically-accessible routines suppHed by the CEE and the up-ca.lmg of 
routmes contained ,n the Imp.ementation Library. The CEE 75 can also receive object calls 82 
from other capsu.es within the same machine and requests 84 from other CEE's The client-side 
CEE 75 and the server-side CEE 85 may communicate using any known networking protocol 

Objects implemented m a CEE capsu.e may be configured or dynamic. Configured 
objects have their implementation details stored in a repository (such as the MSF Warehouse 85) 
or m truncation scripts. Given a request for a specific object reference, the CEE 75 starts the 
appropnate capsule based on this configuration data. The capsu.e uses the configuration data to 
determme which Implementation Library to load and which object initialization routine to call 
The object initialization routine then creates the object. Dynamic objects are created and 
destroyed dynamically within the same capsu.e. Dynamic objects .ack repository-stored or 
scripted configuration information. 

The following paragraphs describe a system-level view of how the Implementation 
libraries interact with the CEE 75. The CEE 75 implements requests to activate and deactivate 
objects wtthin a capsule. In addition, the CEE facilitates inter-capsu.e object calls 82 as well as 
requests from other CEE's 84, as discussed above. Object activation requests arise when an 
object call from a client or server application must be satisfied. To activate an object the CEE 
75 loads the appropriate Implement*™ Library (if not already loaded) containing the object's 
methods and then cal«s a configured object initialization routine contamed in the Implementation 
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Libraries, as discussed below. The initialization routine specifies which interface the 
Implementation Libraries support and registers the entry points of the object's methods to be 
called by the CEE at a later time. 

When the client and server systems start, both the client-side and server-side CEE's run 
5 their own initialization. This initialization tells client and server CEE's where to locate the 
various Implementation Libraries. Once located by the CEE, the CEE calls the initialization 
routines in the client and server applications. The initialization routines contained in the client 
and server applications must first carry out any required application-specific initialization. Next, 
both the client and server initialization routines call a generated stub function which, in turn, 

10 down-calls a CEE function (contained in a dynamic library as stated above) called 
CEE_INTERFACE_CREATE to specify the object's interface. An interface may be specified 
for each object. The interface description is normally generated from an IDL description of the 
interface, as discussed below. CEE_INTERFACE_CREATE creates an interface and returns an 
"interface handle" to the newly created interface. The handle is a unique identifier that specifies 

15 the interface. The server application initialization routine then uses the interface handle to down- 
call CEE_IMPLEMENTATION_CREATE. CEEJMPLEMENTATION CREATE creates an 
implementation description that can be used by one or more objects. 
CEEIMPLEMENTATIONCREATE returns an "implementation handle" that is a unique 
identifier specifying the implementation for each operation in the interface. Finally, the server 

20 application initialization routine uses the implementation handle to call a stub function which 
down-calls CEE_SET_METHOD . C E E_S ET_METHO D specifies the actual addresses of 
specific method routines of the implementation as contained in the server application. The CEE 
then has sufficient information to connect object calls in the client application to specific methods 
in the server application. 

25 

III. Compiling and Linking IDL Source Files 

Figure 4 shows how IDL source files are compiled and linked into client and server 
applications that will utilize the method and apparatus of the present invention. First, an IDL 
source file 101 is prepared containing IDL interface definitions. An IDL compiler 103 compiles 
30 the source file 101. The IDL compiler 103 parses the code 101 to produce an intermediate 

9 
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Pickled [DL file CP, F , nie 105 for SIOrage ^ ^ ^ ^ 

* ,s escnfcd in ^ A ^ ^ m IP 

ft*-*, however, the IDL compiler and code „ are combined „ ^ 
d,=c„y from te TO fi lc . Ue code „ , , , . «* 

^generators „, are used. A,tema,ive,y. the code general 1 1 ] and the IDL compiler 103 

«V b. -mbmed in a si„ g ,e applied t0 prote , angtlage , pKific ^ J 

HI P^uces a Cien, shab » „ conlami „ 6 dte sojb ^ ^ f ^ J ? 

conta.nmg defcMo™ for objec, ta- . The Cien, sab fi,e 77 a „d the server stub m, 

are comp.led by programing ianguage-specific confers 121. ,23 ,o produce compiled" 
*~ «* 0*. code and compiled server snab objec, c „de. SMI a rly , . ^ appfa Z " 
and a server app„c 2t ,o„ 89 are compiled by programmmg-language-specific corners ra pro duce 
compned Chen, a Ppll ca,,„„ object code and comp|w 

apphca„o„ 79 and ,he server applicanon 89 also include , teder r „ e „, „ by ^ 
generator 111. The header fi,e „9 comains common demons and dec,ara,i„„s Finally a 
lang-age compiler 121 links ,he Cent applicauon objec, code and ,he Cien, stub objec, code',0 
produce an implement library 71. Similar*, a second ,anguage compiler ,23 II* me 
«rver a P p„ca,io„ objec, code and ,he server snab objec, cede ,o produce anomer taplementation 

IV Asvnchrnnm,. Client .nH s. ry„ s mh Fn .. 

The code general ,„ gen^s ^ syncnronous ^ asyxtlroms ^ 
tacons in the Cien, stub fi,e 77 for each opera,,„„ in each i„,erface defined in ft e IDL source 
file 101. Each srub funcnon corresponds ,o a parucular opera,i„„ ,„ the iraerfaK($) defined in 
■he IDL scree file ,01. The Cien, application 79 calls these stub functions ,o reuses, tha, an 
operation be performed on an objec. The synchronous Cien, stub talons receive fte 
operauon s inpu, paramcers, and a reference ,„ the object (in the form of a proxy handle, The 
^nchronous Cien, snab fcneion, in rurn. contains a cal, ,„ CEE.OB,ECT CALL (discussed 

stub hancttons receive the input parameters ,„ , requested operation, .he proxy handle at* 
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a pointer to a completion routine address. These parameters are, in turn, passed to a CEE 
function. CEE_OBJECT_CALL_POST, which is also discussed in greater detail below. 

The code generator 111 similarly generates synchronous and asynchronous server stub 
functions in the server stub file 87. Each stub function corresponds to a particular operation in 
5 the interface(s) defined in the IDL source file 101. The server application calls these stub 
functions to notify the CEE of which methods to up-call in order to implement the interface 
operation that corresponds to the stub. The synchronous server stub function for each operation 
receives an implementation handle (returned from the call to 
CEEJMPLEMENTATIONCREATE) and the address of a method in the server application. 

10 The synchronous server stub function, when called in the server application, calls 
CEE_SET_METHOD to connect the server application method to the operation specified by the 
stub. When requests for particular operations arrive at the server-side CEE, the CEE up-calls the 
appropriate method in the server application based upon the address that has been set for the 
requested operation. When the server application method returns, the server-side CEE will 

1 5 transmit a response back to the client. 

The code generator 111 generates a stub function to handle asynchronous object 
implementation. The asynchronous server stub function is similar to the synchronous stub 
function, in that the asynchronous stub function receives (from the server application) the 
implementation handle and the address of a method to up-call from the server application. The 

2 0 asynchronous stub function, in turn, calls CEE_SETJvlETHOD, which connects the server 
application method to the operation corresponding to the stub. This call to CEE_SET_METHOD 
also notifies the CEE (via a parameter to CEE_SET_METHOD) that the method is to be 
implemented asynchronously. Since the up-called server application method is asynchronous, the 
CEE will respond to the client upon a call to a generated response stub function also contained in 

25 the server stub file 87. The generated response stub function receives the operation's output 
parameters and a call identifier. These parameters are passed to a CEE function, 
CEE_RESPOND (described below), which responds to the client application. 



V. Synchronous and Asynchronous Calls and Implementations 
30 A. Synchronous Call/Svnchronous Implementation 
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30 The funcion receives fc objec, reference. CJreJ. and an in,erface handle. tw 
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by CEE_INTERFACE_CREATE (described above), and returns a proxy handle identifying the 
newly created proxy object. The details of proxy creation and a description of the proxy handle 
structure returned by CEE_PROXY_CREATE are described below in Sections VI and VII. 

The proxy handle returned by CEEPROXYCREATE is a structure containing a pointer 
5 to the object if the object is in the same capsule or a pointer to a client port if the object is not in 
the same capsule. The client-side CEE also uses the proxy to store a completion routine address 
that is used in ah asynchronous object call (discussed below). The completion routine will be 
discussed below with reference to asynchronous calls from the client application. In a 
synchronous object call, the address of a completion routine is not stored in the proxy handle 
10 structure. 

In step 505, the client calls the object. Specifically, the client application requests that an 
operation of an object's interface be performed on the object by calling the appropriate generated 
synchronous stub function which, in turn, contains a down-call to CEE_OBJECT_CALL. 
CEE_OBJECT_CALL is defined in C as follows: 
1 5 CEE_OBJECT_CALL ( 

const char "proxy Jiandle, 
long "operation Jdx, 

void *param_vector); 

20 The stub function receives the proxy handle and the input parameters to the operation. The stub 
function provides CEEOBJECTCALL with three parameters. The first parameter is the 
proxy Jiandle. This parameter specifies the object to be called and will be used to respond to the 
call. The second parameter, operation Jdx, is an integer that specifies which of the object's 
methods is to be called. The identifier is used locally by the client to specify a particular 

2 5 operation. The identifier saves the client the trouble of repeatedly performing string comparisons 
on the operation name. Similarly, on the server side, the server specifies operations using its 
own operation identifier. The param_vector is an array containing the addresses of the object 
call's input parameters, output parameters and exception structure. The address of the exception 
structure preferably is the first element in the array. If the operation is not of type void, then the 

30 following element in the array contains the address of the variable to receive the operation's 
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Next, in step 605, the object is called using a generated asynchronous client stub function. 
This generated asynchronous stub function receives the object's proxy handle, the input 
parameters to the operation, a call tag (described below) and the address to a "completion 
routine" within the client application. The completion routine will be called by the client-side 
5 CEE when a response to the object call has returned. The asynchronous stub function, in turn, 
down-calls a client-side CEE function, CEE_OBJECT_CALL_POST, which calls the object. 
CEE_OBJECT_CALLJPOST is defined in C as follows: 
CEE_OBJECT_CALL_POST ( 

const char "proxy handle, 
10 long operation jdx, 

const void "const *param_vector, 
void completion joutine , 

char calljagl); 

1 5 The stub function provides the proxy handle for the requested object and an operation index that 
specifies which of the object's operations is to be performed. The param_vector parameter 
supplied here is an array containing the addresses of the object call's input parameters only. The 
input parameters are stored in the array in the same order as they were defined in IDL to permit 
object calls across multiple platforms. The calljagl parameter is a constant used to identify this 

2 0 call to the object 

The asynchronous client stub function and CEE_OBJECT_CALL_POST also receive the 
address of a "completion routine" in the client application that will be called by the client-side 
CEE 75 when a response to the object is returned to the client application or an error condition 
(or other exception) has been received by the client-side CEE. In step 607, the client-side CEE 

25 stores the completion routine address in the proxy handle for later use. When the call returas for 
a particular proxy handle, the client-side CEE will extract the completion routine address from 
the proxy structure and call the completion routine. The completion routine will be discussed 
below. If multiple calls are made requiring the same completion routine, the calljagl parameter 
may be used to identify a particular call within the completion routine. The calljagl parameter 

30 is also stored in the proxy structure in step 607. 
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stub function which will call CEE_INTERFACE_CREATE. The CEE returns an interface 
handle, intf. to the client. (The variable sts (status) is a dummy variable that allows the function 
return value to be examined when debugging.) 

At line 703, the client obtains an object reference from a configuration file previously 
5 registered with the CEE. The reference, objref, refers to an object of the Time interface. 
Because the client application plans to call TIM_Now twice and simultaneously, the client uses 
the object reference to create two proxy handles at lines 705 and 706. The client calls 
CEE_PROXY_CREATE which returns proxy and proxy 1. 

At line 707, the client calls the Time object using the asynchronous stub function, 

10 Tim_Nowjpst. The client provides the first proxy handle (proxy), a completion routine tag 
(LOCAL TTME TAG), and an input parameter {LOCAL). At line 708, the client continues to 
perform other asynchronous work by making another call to the same object using a different 
proxy handle (proxy 1), completion routine tag (GMTJTAG), and input parameter (GMT). If the 
first call were made synchronously, the client application would be required to wait until the first 

1 5 call to Tim_Now returned before making the second call to Tim_Now. 

For both calls, the client-side CEE stores the completion routine address and completion 
routine tag in the proxy structure. The client-side CEE 75 transmits both requests to the server- 
side CEE 85. The server application contains an implementation for the Tim_Now operation. 
This implementation (not shown) provides the local or GMT time. The time is inserted into an 

20 output parameter and the output parameter and any exception information are transmitted back to 
the client-side CEE 75. 

The client-side CEE determines which call has returned and calls the completion routine 
for the returning call. The completion routine of the example is shown beginning at line 709. A 
switch statement at line 710 receives the optional completion routine tag parameter. If the tag 

25 value is LOCAL, the function will print the local time as shown at line 711-712. If the tag value 
is GMT, the function prints the GMT time as shown at line 713-714. Another example of a 
completion routine tag would be that the CEE assigns sequential tag numbers each time it makes 
a new function call to an object. 

30 B. Asynchronous Implementation 
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In step 809. the original method calls an asynchronous method to carry out another 
function. For example, the original method may need to perform an asynchronous input/output 
operation such as opening or closing a disk file. Alternatively, the original method may make an 
asynchronous object call, itself, to carry out some function. If the original method calls an 
5 asynchronous method, the original method preferably provides the asynchronous method with the 
address of a response function in the server application. When the asynchronous method 
completes, the asynchronous method will call the response function. In addition, the 
asynchronous method receives the context variable containing the call identifier and the result of 
any operations performed in the original method. The context parameter will ultimately be used 
10 by the response function in order to associate the response to a particular object call. 

The asynchronous method performs its designated function. When completed, the 
asynchronous method calls a response function in step 811. The asynchronous method passes the 
context parameter containing the call identifier and output parameters (as well as any other 
context that may be useful) to the response function. The response function, in turn, calls the 
15 asynchronous response stub function in the server application in step 813. As discussed above, 
the response stub function contains a down-call to CEERESPOND. If the original method had 
not called an asynchronous method, but was specified as an asynchronous method in the 
initialization routine, the original method could have called the asynchronous response stub 
function directly. Alternatively, any method in the server application can call CEE_RESPOND. 
2 0 CEE_RESPOND is defined in C as follows: 
CEE RESPOND ( 

const char *call_id t 

const void *const *param_yector)\ 

25 The response function transmits the call identifier to the stub function by extracting the call 
identifier from the context. The stub function transmits the identifier to CEE_RESPOND. The 
server-side CEE locates the call identifier in the server computer memory and responds to the 
appropriate call based upon the call identifier. The response contains the paramjvector 
parameter which is an array containing pointers to the object call's output parameters and 

30 exception structure. The first element of the array is the address of the exception structure. If 
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waiting for control to return from CEE_TIMER_CREATE. 

When the timer pops, the CEE calls the response function, TimerExpired. 
TimerExpired, at line 910, contains a single call to a server stub response function. The server 
stub response function, preferably, calls CEEJRESPOND. The call to the server stub response 
function extracts the call identifier and the output parameter, timestr. The server-side CEE 
transmits the output parameter (and exception information, if any) back to the client-side CEE 
75, in a manner dependent on whether the original call was made synchronously or 
asynchronously. 

C. Asynchronous Implementation With Memory Allocation 

Because multiple calls can be made to the same method in the server application, the 
method should preferably have some method for allocating and deallocating memory for 
numerous calls. In an alternative embodiment of the method and apparatus of the present 
invention, memory allocation and deallocation ("garbage collection") during object 
implementation is provided. Figure 10 shows this alternative method of the present invention. 
Steps 1001-1005 are similar to the steps involved in Figure 6. Thus, in step 1001, the object is 
called asynchronously or synchronously. Next, in step 1003, the request is transported from the 
client-side CEE to the server-side CEE. The server-side CEE then up-calls the appropriate 
method in the server application in step 1005. 

In step 1007, the server application allocates memory for the call. This is accomplished 
by calling an appropriate memory allocation function, such as MALLOC in C and C++. A 
mechanism must also be provided to deallocate previously allocated resources. Preferably, 
memory allocation and deallocation is performed by down-calling CEEJTM P_ ALLOC ATE , 
defined in C as follows: 

CEEJTMP_ALLOCATE ( 



const char 



*catl id 



long 



len 



void 



ytr 



The calljd parameter identifies the particular call so that the CEE can automatically deallocate 
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application. That function is defined in the C programming language as follows: 
CEE_PROX YCREATE ( 

const char *objref, 
const char *intfj\andle, 
char * proxy Jiandle) ; 

The function receives the object reference, objref, and an interface handle, intfjiandle, and 
returns a proxy handle identifying the newly created proxy object. As discussed above, in 
connection with Figure 3, an interface must be created for each object. An interface defines the 
operations available for a collection of similar objects. The interface is defined in IDL and 
compiled and linked into a client application. The client application calls 
CEE_INTERFACE_CREATE in its initialization routine to specify the interface. The client-side 
CEE returns an interface handle that can be used to create any number of objects or proxies. 

In a preferred embodiment of the present invention, the proxy object is represented by a 
structure containing the following fields: 

link; 

call Jink; 
self; 
nor; 
state; 

call_active; 
destroy; 
lockjoount; 
*intf; 

callj:ompljtn; 
calljcompljagl; 
call joomplt Jag2; 
calljcompljsts\ 
operation _idx; 
*client_allocated jparams; 
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*server_allocated j>arams\ 

operation Jdxjable\ 

maxjesponsejize\ 

*reqjirea\ 

*rsp_area\ 

*rsp j)aramj>uf\ 

ochan\ 
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Each of the components of ,he proxy objec, data structure win now be discussed The 
addresses and values stored ■„ each of rhese components is modified by the ciiem-side CEE wirh 
each cai, ,o ,he objec, referred t o by the proxy structure. The c,ien,-side CEE tna.ntains a iinked 
1« of proxy srructures. The a* member of each proxy structure contains a potnter ,o the nex, 

entry m this list of proxy structures. 

In a preferred embodiment, object calls can be either synchronous (client appHcation 
requests that an operation be performed on an object and wa.ts for a response) or asynchronous 
(chent app.ication requests that an operation be performed on an object and continues to do other 
work). When asynchronous object calls are dtspatchcd in the same capsule, each call is queued 
onto a hnked list contained in an object structure that exists for every object when activated The 
callUnk parameter is a Hnlc to the list of calls. The self member is the handle of this particular 
proxy structure. This handle is returned to the client during CEE PROXY CREATE 

The object reference passed to CEE PROXY CREATE is storcd~in the nor member 
The state parameter indicates whether the proxy structure mcludes a po.nter to an internal object 
structure, an externa, object (via a client port), or a non-existing object structure (is stale) if the 
proxy 1S mterna,, a pointer to the object is contained in the obj parameter. If the object is in a 
Afferent capsu.e, the ochan parameter contains a pointer to a client port hand,e or other 
information required to communicate with the object. 

The cal L acu ve member holds a true/false value. The cal L act lV e member is set to true if 
an object call is outstandmg for th.s particular proxy handle. Only one object call can be 
outstanding on a given proxy. The lockjount member is incremented to prevent the proxy 
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structure from being destroyed. It is decremented when the structure is no longer needed. The 
destroy member is a true/false value that is set to true if this proxy structure should be destroyed 
when lockjount drops to zero. The intf member is the address of the intf structure that describes 
the interface (discussed above). 
5 The next four structure members. call_compl_rtn, calljoompljagl , callj:ompljag2, 

call_compljts, are used to implement asynchronous object calls. Asynchronous calls to an 
object in a server application are made by passing the address of a completion routine to the 
client stub function when called. The client stub function, in turn, calls the client-side CEE and 
provides the completion function address. The client-side CEE stores the completion function 

10 address in the proxy structure upon creation of the proxy handle. When the object call 
completes, the client-side CEE calls the completion routine specified in the proxy handle. The 
routine is called to notify the client application that the call has completed. While the object is 
being implemented, the client application can continue performing other functions. The member 
calljzompljrtn contains the address of the completion routine. Since multiple calls may be made 

15 to the same proxied object, the client application can identify the call by using the 
call _compl jag 1 parameter when the object call is made. The call _compl jag 1 identifier is 
passed to the client stub function. These identifiers are specified in the proxy structure by the 
members calljiompljagl and callj:ompljag2. The calljcompljts indicates the call 
completion status for asynchronous calls that could not be called. 

20 The operation Jdx member specifies which of the object's operations is to be called. 

Operation identifiers are generated by the code generator for each operation in the interface. The 
allocated jiarams member is a pointer to the parent of temporarily allocated parameters (used for 
unbounded types and the like). The deallocation of this member performs garbage collection on 
the next call to the object referenced by this proxy structure. The operation Jdx jabl'e parameter 

2 5 is a pointer to an operation index translation table that is used only if the object is contained in the 
same capsule. 

Memory allocation is performed utilizing the maxjesponsejize, reqjirea, rspjirea, 
and rsp _paramj>uf members. The rsp jparamjnif member points to a buffer containing the 
response parameters. The next time that this proxy object is used, the buffer will be deallocated. 
30 The maxjesponsejsize member is the maximum expected response size. This is used to 
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all by the client application to CEE.PROXY_CR£ATE causes the client-side CEE 
o _ aIly all memory for the object m ^ j ^ ^ - CH 

^ addkl0nal ~ ™ for ma k in g the ca,.. Once the P oxy 

h and,e , destroyed ( thr 0Ugh . down . call t0 CEE PROXY DESTROY, discussed below th 
memory and any al.ocated resources are freed. Memory abated for variab.e-stzed output 
^ =m an 0bj ect cal, are debated when the ne X t object cail 1S m ade u Sing the sale 

oroxv tT T h3ndle " US£d ,0 a " SUbSeqUem C3l,S 10 thC ^ - by the 

y The object cal, is m ade in step ,,,1 by calling the appropriate stub Action in the client 

apphcanon and P ass,n g the proxy hand.e and tnput and output parameters a«on g with exception 
******* to the function. The stub function, in turn, down-cal.s CEE OBJECT CALL 
defined in C as follows: " - L ' 

CEE_OBJECT_CALL ( 

const char "proxy Jandle. 

long operation Jdx, 

V0ld **param_vector); 

The proxy ha* is specified hy *. pmx y Mle paranKKr ^ 

w ,ch or ,he ohjec, ™hods is t0 he ca„ed. This „ „ an Wex ,1 ^ 
method ,„ ,he ,„,e rf ace de.rip.ion .hat was supphed ^ the tecrface was ^ 
P°r~r parameter is an array „ f ^ t0 Ihe objM ca „, ^ ^ 
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parameters, and exception structure. The address of the exception structure is the first element in 
the array. If the operation is not of type void, then the following element contains the address of 
the variable to receive the operation's result. Subsequent elements contain the addresses of the 
operation's input and output parameters in the same order as they were defined in IDL. 

The call is then transported to the server using any transport mechanism. In step 1115, 
the server application implements the object. This is performed by the server-side CEE which 
up-calls the appropriate method routine. The method routine is passed the param_vector 
parameter containing the addresses of all the input and output parameters. When the method 
exits, a response is sent to the caller in step 1 1 19 and the object call is complete. 

Once the first call has completed, the proxy handle may be used again to make further 
calls to the same object. Each subsequent call to the object may be made without validating the 
object or performing other start-up operations. Thus, the proxy creation step can be placed in a 
non-time-critical portion of the client application and object calls can be made in a time-critical 
portion of the application. 

Following the final object call for a specified proxy handle, the proxy handle is destroyed 
in step 1121. This is accomplished by calling CEE_PROXY_DESTROY in the client 
application, defined in C as follows: 

CEE_PROXY_DESTROY ( 

const char *proxy_handle)\ 

The proxy handle is passed to the function. The client-side CEE destroys the proxy handle and 
frees all previously-allocated resources for the proxy handle in step 1128. Alternatively, an 
object call may be canceled and all of the resources associated with the call may be deallocated 
by destroying the proxy while the call is outstanding. 

VII. Proxy Creation And Memory Allocation 

Figure 12 shows an alternative embodiment of the object call method of the present 
invention. In this embodiment, memory is allocated during the implementation of the object as 
well as during the object call. 

Steps 1201-1211 are similar to the steps described above. Thus, in step 1201, an object 
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CEE.PROXY.CREATE wh,ch returns the proxy handl , The 

' 2 " US ' ng CEE -°^-CALL. which B passed , he proxy ^ Qf , hc referenced object «"> 
<n step 12B, «he server-side CEE up-ca,ls the appropriate method routine i„ ,„e server 
PPhcatton. The method routu*. i„ step 1216 when ca , |ed . down<a , ]s , ^ ^ 

CEE ™ :::r Thai ^ ^-^^ - «- * c - ^ 

CEE TMP ALLOCATE ( 

const char *calljd, 
lon S /«, 



VU1U 



*ptr)- 



The Sanction „ ses te ^.parameter ,o track a particuiar object ca„. Each ca„ ,o the ot,ec, is 
g,v=n a uniaue M „ by lhe ^ver apphcation. Thus, once ,he ca„ is mace, the server 
ylementation provides an id fo, ,he cai, i„ ,he caUJ d parameter. The number of byes „ 
-5 aliocate ,s specified i„ the len parameter. The fcnction ,« te adtes of ^ ^ 
memory through the ptr parameter. 

The object's method ,s performed by the server application in step 1219 The server 
apphcation responds to the caller in step 1215. Upon exiting the method function, the memory 
allocated under the down-call to CEE_TMP_ALLOCATE , freed m step 1220 The client 
apphcation then makes another object ca., in step 1211 or destroys the proxy hand.e in step P25 
If the proxy hand.e is destroyed, the memory a.located in step 1209 is automatical deallocated 
by the client-side CEE in step 1228. 

Memory can be prematurely deallocated using CEE TMP DEALLOCATE That 
function is defined as: ~ 

25 CEE_TMP_DEALLOCATE ( 

1° void *ptr); 

The function is passed the ptr parameter that was provided by CEE TMP ALLOCATE The 
CEE frees the address pointed to by that parameter. 
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VIII. Creating a Pickled IDL Format Data Structure 

The Pickled IDL Format ("PIF") data structure is designed to be used in conjunction with 
IDL compilers and code generators loaded in the client memory 23 and server memory 17. The 
data structure is based upon an IDL source file stored in memory 23 or in memory 17. The 
5 source file may also be contained on a computer-readable medium, such as a disk. The data 
structure of the present structure contains a parse tree representing the IDL source file. The data 
structure can be stored in memory 23 or in memory 17 or on a computer-readable medium, such 
as a disk. The data structure that represents the source file is referred to as a Pickled IDL 
Format ("PIF"). The PIF file can be accessed at run-time by clients and servers that use the 
10 interfaces defined in the source file. The parse tree contained in the PIF file is an array using 
array indices rather than pointers. The use of array indices permits the resulting parse tree to be 
language-independent. The first element of the array is unused. The second element of the array 
(index 1) is the root of the parse tree that acts as an entry point to the rest of the parse tree. 
The data structure, tu 1301, is shown in Figure 13, and defined in IDL as follows: 
15 struct tu_def { 

sequence < entry_def > entry; 
sequence < string > source \ 

} 

20 The data structure 1301 contains a sequence (a variable-sized array) of parse tree nodes 1305, 
each of type entry _def (defined below) and a sequence of source file lines 1307. The sequence of 
source file lines 1307 is a sequence of strings containing the actual source code lines from the 
IDL source file. 

Each parse tree node (or "entry") 1305 consists of a fixed part containing the name of the 
25 node and its properties as well as a variable portion that depends upon the node's type. The 
parse tree node is shown in Figure 14 and defined in IDL as follows: 
struct entry _def { 

unsigned long entry Jndex\ 
string name\ 
30 string filejiame\ 
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unsigned long linejir, 

boo,ea " in main Jle; 

union ujag switch (entry jype_def) { 

case entry_ar g um ent : argum en t_d e f argument entry; 

case entry_array: array_def array entry; 

case entry_attr: attr_def attr_entryi 

case entry const: const_def const_entry; 

case entry_enum: enum def enum_entry; 

caseentry_enum_val: enum_val_def en Um _val entry; 

case entry_except: except_def except def entry" 

case entry_field; field_def fieldjef entry- 

case entryjnterface. interface_def interface entry- 

caseentryjnterface_fwd; interface_fwd_def interface fwd entry- 

caseentry^oduleimodule.defmodule.emry; " " ' 

case entry_op: op_def op_entry; 

case emryj^defined: pr e _defined_def pre defined entry- 
case entry_sequence: sequence_def sequence_entry; " 
case entry_string: string_def string entry; 
case entry_struct: struct_def struct_entry; 
case entry_typedef; typedef_def typedef_entry; 
case entry_union: union_def union entry; 
case entry_union.branch: uni 0n _br"anch_d e f U nion_branch_entry; 



}; 



25 



}u; 
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The fixed pan of the parse tree node includes entry index 1405 1n • , 

- *e index for this particular entrv in the parse tree T~ ' ° *»* 

contained in the field name 1407 The n \ " " ° f ** is 

**Jlk name 14, 1 Z: r ^ iS " » - 

~ - - tie ^ZT^ ^ " * ^ — * * 

created. The boolean m main Jle 1415 indicates whether or 
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not the entry is made in the IDL source file specified on the command line or whether the entry is 
part of an "include" file. Following these fields, the parse tree node includes a variable portion- 
a union 1417 having a discriminator, entry jypejief. The union discriminator, entry jypejief, 
specifies the type of node and which variant within entry jlef is active. Entry jypejief is an 
5 enumeration defined as follows: 
enum entry_type_def { 
entry_unused, 
entry _module, 
entry_interface > 
10 entry_interface Fwd, 

entry _const, 
entry_except, 
entry_attr, 
entry_op, 

1 5 entry ^argument, 

entry _union, 
entry _union_branch, 
entry _struct, 
entry _field, 

20 entry _enum, 

entry _enurn__val, 

entry ^string, 

entry_array, 

entry _sequence, 
2 5 entry_typedef , 

entry_pre_defined 

}; 

30 Entry jypejief includes a list of the various types of parse tree entries. Each parse tree entry 
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7™ 2 C0K ' am in,C8e ' ^ " ^ in *• «— contained in «, 4/ For ^ 

en^unused corresponds , 0 ^ valuc m a „ d , s „ ot ^ jn deKmiin|ng ^ ^ ^ 
If parse tree enay is a ^ (spccjfjed by ^ ^ 

zir:r ^ en,ry is a dau • — * — *«c 

mCdU,e defmti °" " « ^ «* as an index ,n the parse tree array 

If the parse tree entry is an interface, as specified by the value entry interface th, 
vartable por,,o„ of tne parse tree is a data suture including a seance of J^J". 

:r:irr. ime : f ™ hm *** *■ — « * - - «, * a ,2; 

le "~-^' - - > - — - e cc„ aW „g the 

value of IT"" ™ '™ " 3 ™* " ' «"»« — - 

va ue of *e constant. A union a* sw,,ch,case statement are preferably used ,o discrimLe 

^een *e vanous base w constants (boolean co,s,a„, char consent, d oub,e cons™ etc 
that may be included in the source file. ' 

Exceptions (ent^except, are represented in a parse tree „c* as a stntctur. containing a 

zr : r An a,,nbuKs ^ - ~ - • - — 

tTdl r wtaher ,he a,,ribme is read "° n,y and m ,0 " 8 « ha « 

If UK parse tree entry is an operation (o p _def). the vartable ponton 1417 of the entrv dan, 
strucre 1 05 is a data s m c.re as shown in H gu re „ Thc data slrucnjre j£[ 

Z 1 T"" or ~ * — te a — «*■»• » 

S .307 ha, ,„d,cates the return W e. a seance of arguments 1509 to the operation, a 
eq^nce of exceptions l51 , to the operation, and a sequence of strings I5B tha, specify any 
0 .ex, mcluded in the operation. ,f .e parse tree entry is an argument to a parttcular opelio 
^.argument,. ,he variab,e ponton of ,he parse ,ree e„,ry is a structure couuuung unsigned 
longs fna, mdicate the data type and direction of the argument 

If .he parse ,re= en,ry ,s a umon <en,ry_uni„„, ,, , ^sented ,„ ,h e paree tree entry as 
hown ,„ figure ,6. da ,a stntchrre ,4,7 contams an united ,„„ g spKifyim ae 

1603 and an unsigned tong spec W „ g ,h e , ype I6 „, The ^ s ^ 
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specified using an enumerated list of base types. The structure 1417 further includes a sequence 
of the union's fields 1607. If the parse tree entry is a union branch (entry _branch), the variable 
portion of the parse tree entry is a structure containing an unsigned long indicating the base type 
of the branch, a boolean indicating whether or not the branch includes a case label, and the value 
5 of the discriminator. Since the value is of a particular data type, preferably an enumerated list of 
the various base types is used to specify the value within the structure used to represent the union 
branch. 

For data structures (entry_struct), the variable portion of the parse tree entry includes a 
structure containing a sequence of the specified structure's fields. Enumerated values 
10 (entry _enum) are represented by a structure containing a sequence of enumerated values. 
Enumerations of an enumerated type (entry _enum_val) are represented in the parse tree entry by 
a structure containing an unsigned long holding the enumeration's numerical value. 

If the parse tree entry is a string (entry_string), the variable portion of the parse tree entry 
is a structure containing the string's maximum size. A maximum size of zero implies an 
15 unbounded string. An array (entry _array) is represented in the parse tree entry by a structure 
containing an unsigned long holding the array's base type and a sequence of longs holding the 
array's dimensions. A sequence (entry_sequence) is represented by a structure containing 
unsigned longs holding the sequence's base type and the sequence's maximum size. 

For type definitions (entry_typedef), the parse tree entry includes a structure containing 
20 an unsigned long value indicating the type definition's base type. Predefined types 
(entry _pre_defined) are represented by a structure containing the data type. To specify the type, 
preferably an enumeration of the various base types are used. 

Once the IDL source file has been described using the tu data structure, the data structure 
may be transported to a file or database using any known methods. 

25 

Having thus described a preferred embodiment of a method for asynchronously calling 
and invoking objects, it should be apparent to those skilled in the art that certain advantages of 
the within system have been achieved. It should also be appreciated that various modifications, 
30 adaptations, and alternative embodiments thereof may be made within the scope and spirit of the 
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CLAIMS 

What is Claimed is : 

5 

1. A method for asynchronously performing an operation on an object, the operation 
being requested by a client application to a server application, the method comprising the steps 
of: 

obtaining an object reference to the object in the client application; 
10 requesting the operation with a stub function in the client application, the stub function 

being passed the object reference, an input parameter of the operation, and a computer memory 
address of a completion routine in the client application; 

storing the completion routine memory address; 

transmitting the input parameter to a method in the server application via an execution 
15 environment accessible to the client application and the server application;; 

implementing the operation on the object in the server application, the implementation 
including a response to the client application; 

transmitting the response to the client application via the execution environment; 

calling the completion routine in the client application, the completion routine being 
20 passed the response. 

2. The method for performing an operation on an object, as recited in Claim 1, wherein 
the object reference is obtained from a configuration file accessible to the client application. 

2 5 3. The method for performing an operation on an object, as recited in Claim 1, wherein 

the object reference is obtained from a disk file accessible to the client application. 

4. The method for performing an operation on an object, as recited in Claim 1, wherein 
the object reference is obtained from a previous object call by the client application. 

30 
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5 the . \ ^ "T" 10 " Perf0 " nm8 ™ 0Pera,km °" ° bjKI - « «*- *■ Claim 5 wherein 

* *ep „ f asynchronous, imp|5men , ing , he op£mjon ^ me objM ^ ^ .J*. 

caMng an asynchronous .taction from within ,he server app.ica.ion method the 
«o U s ft.nc.ion being ^ . cal , jdsraife and , _ oiy addrKs * ^ 

function m .he server application; response 

1 0 caning Che response mncion from u,e asynchronous function, passing ihe cal, identifier ,„ 

the response function; and "rainier .o 

responding to .he objecl call based upon die identifier. 

7. A method for ^ch™^ a „ on ^ 

1 » c,,e„, colter app.ica.ion .o a server co mp u,er app.ica.ion. the method conning " 
ob.a, ra „g an objec. reference to represent the object 

passed r'''ob !' T ' "* te ' i0 " '" *" * "* 

passed U, obm reference , a „ inpu , parameBr Qf operatta ^ a I 

address ofacompteion routine in OKclien.applica.ion 

20 vi, an ^ ™ ^ «*" ^ » a -*»' * *» -» aPPli-ion 

v.» an „ e„ vironrae „, access,b,e to the c.ien. app.ication and the server app.icatio' 

server 1 , " aSynChr °"° US a ^ - a 

server compu,er response (unci™ memory address to the asynchronous function- 

« - jri!:.:^ fcnct ™ from ,he ~° us ^ *- - — - 

responding to the object call based upon the identifier; 

transmitting the response to the caller via the execution environment- 

calhng the completion rounne, the com P ,etion routine being passed the response. 
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8. A method for asynchronously performing an operation on an object via a request by a 
client computer application to a server computer application, the method comprising the steps of: 

obtaining an object reference to represent the object; 
creating a proxy handle to represent the object reference; 
5 calling the object with a stub function in the client application, the stub function being 

passed the proxy handle, an input parameter of the operation, and a client computer memory 
address to a completion routine in the client application; 

transmitting the input parameter to the server application via an execution environment 
accessible to the client application and server application based upon the proxy handle; 
10 implementing the operation on the object in the server application, the implementation 

including a response to the client application; 

transmitting the response to the client application via the execution environment; 
calling the completion routine in the client application, the completion routine being 
passed the response. 

15 

9. The method for performing an operation on an object, as recited in Claim 8, wherein 
the object reference is obtained from an initialization routine in the client application. 

10. The method for performing an operation on an object, as recited in Claim 8, wherein 
20 the object reference is obtained from a disk file. 

1 1 . The method for performing an operation on an object, as recited in Claim 8, wherein 
the object reference is obtained from a previous object call. 

2 5 12. The method for performing an operation on an object, as recited in Claim 8, wherein 

the step of implementing the operation on the object is performed asynchronously. 

13. The method for performing an operation on an object, as recited in Claim 12, 
wherein the step of asynchronously implementing the operation on the object further comprises 
30 the steps of: 

37 



BNSOOCIO: <WO 9802809A1_I_> 



5 



15 



20 



25 



WO 98/02809 

PCT7US97/11879 

calling an asynchronous ^ from within ^ 
response fusion address to the asynchronous and a 

- ^r^irr ta,io ° from * e — — • — * - - 

responding to the object call based upon the identifier. 



of: 



■4. A method f„ r pe rforming a „ optraIjon m ^ ^ ^ ^ ^ ^ 

I":! I TO ' S3d tei0n - ~ - •«*« «n 8 passed a„ identifier 



w .ww.i.iij, U1C uujcci oeing called; 



30 



ca,.,ng an asynchronous taio „ from w „ hin ^ ^ 
to the asynchronous function; and 'aentuier 
responding to the object call based upon the identifier. 

15. The method for perforrmng an operation on an object, as recited in Claim 14 further 
comprising the steps of: ' ™ er 

allocating a portion of the server computer memory to handle the object call- and 
^ defeating the portion of the server computer memory after responding', the object 

16. A computer program product, comprising: 

perfo Jo" " KdiUm taVmS C0 ^' er readab ' e °* — ~ <* 

~ 0Pera "° n °" M ^ 3 fr0m 2 *" — ~ - ■ -er 

computer appltcatton. the computer readabi, program code means comprising 

software meat* for a „ objecI ^ ^ ^ 

stuh * f ° r Cam " 8 * «*« » «* Action h the cien, app.ica.ion the 

17'°" 8 ^ ^ " **» ~ ° f «» — - a cue™ 
computer memory address ,„ a compietion route i„ the dien, appiication- 

software means for transmitting the object reference, i„p« parameter, and completion 
™.me address to an execution environ, access*, to the Cien, appiicarion ahd the ^ 
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application; 

software means for transmitting the input parameter to a method in the server application 
via the execution environment based upon the object reference; 

software means for implementing the operation on the object in the server application, the 
5 implementation including a response to the client application; 

software means for transmitting the response to the client application via the execution 
environment; 

software means for calling the completion routine in the client application, the completion 
routine being passed the response. 

10 

17. The computer program product, as recited in Claim 17, wherein the software means 
for causing one of the first computer and a second computer to implement the operation on the 
object further comprises: 

software means for calling an asynchronous function from within the server application 
15 method, passing a call identifier and a response function address to the asynchronous function; 

software means for calling the response function from the asynchronous function, passing 
the call identifier to the response function; and 

software means for responding to the object call based upon the identifier. 
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